现状
闲鱼IM框架构建于2016-2017年，期间多次迭代升级导致历史包袱累积多，后经IM界面Flutter化，造成架构更复杂，开发层面总结闲鱼当前架构主要存在如下几个问题：•研发效率较低：当前架构开发需求涉及到Android/iOS双端的逻辑代码以及Flutter的UI界面代码，定位问题往往只能从Flutter UI表象追查到Native逻辑漏洞；•架构层次较差：架构设计上分层不清晰，业务逻辑夹杂在核心的逻辑层致使代码变更风险大；•性能测试略差：核心数据源存储Native内存，需经Flutter Plugin将数据源序列化上抛Flutter侧，在大批量数据源情况下性能表现较差；•定位问题困难：线上舆情反馈千奇百怪，测试始终无法复现相关场景，因此很多时候只能靠现象猜测本质；•疑难杂症较多：架构不稳定性造成出现的问题反复出现，当前疑难杂症主要包括未读红点计数，iPhone5C低端机器架构，以及多媒体发送等多个问题；•问题差异性大：Android和iOS两端逻辑代码差异大，包括现存埋点逻辑都不尽相同，因此排查问题根源时候双端都会有不同问题根因，解决问题方案也不相同；业界跨端方案
为解决当前IM痛点，闲鱼今年特起关于IM架构升级项目，重在解决客户端中双端一致性痛点，初步设想方案就是实现跨端统一的Android/iOS逻辑架构；在当前行业内跨端方案可初步归类如下图架构，在GUI层面的跨端方案有Weex,ReactNative,H5,Uni-APP等，其内存模型大多需要通过桥接到Native模式存储；在逻辑层面的跨端方案大致有C/C++等与虚拟机无关语言实现跨端，当然汇编语言也可行；此外有两个独立于上述体系之外的架构就是Flutter和KMM（谷歌基于Kotlin实现类似Flutter架构），其中Flutter运行特定DartVM，将内存数据挂载其自身的isolate中；
考虑闲鱼是Flutter的前沿探索者，方案上优先使用Flutter；然而Flutter的isolate更像一个进程的概念(底层实现非使用进程模式)，相比Android，同一进程场景中，Android的Dalvik虚拟机多个线程运行共享一个内存Heap，而DartVM的Isolate运行隔离各自的Heap，因而isolate之间通讯方式比较繁琐（需经过序列化反序列化过程）；整个模型如下图所示：
若按官方混合架构实现Flutter应用，开启多个FlutterAcitivty/FlutterController，底层会生成多个Engine，对应会存在多个isolate，而isolate通讯类似于进程通讯（类似socket或AIDL），这里借鉴闲鱼FlutterBoost的设计理念，FlutterIM架构将多个页面的Engine共享，则内存模型就天然支持共享读取，原理图如下：
Flutter IM架构设计
新老架构对比
如下图是一个老架构方案，其核心问题主要集中于Native逻辑抽象差，其中逻辑层面还设计到多线程并发使得问题倍增，Android/iOS/Flutter交互繁杂，开发维护成本高，核心层耦合较为严重，无插拔式概念；
架构从上至下依次为业务层，分发层，逻辑层以及数据源层，数据源层来源于推送或网络请求，其封装于Native层，通过Flutter插件将消息协议数据上抛到Flutter侧的核心逻辑层，处理完成后变成Flutter DB的Enitity实体，实体中挂载一些消息协议实体；核心逻辑层将繁杂数据扁平化打包挂载到分发层中的会话内存模型数据或消息内存模型数据，最后通过观察者模式的订阅分发到业务逻辑中；Flutter IM重点集中改造逻辑层和分发层，将IM核心逻辑和业务层面数据模型进行封装隔离，核心逻辑层和数据库交互后将数据封装到分发层的moduleData中，通过订阅方式分发到业务层数据模型中；此外在IM模型中DB也是重点依赖的，个人对DB数据库管理进行全面封装解，实现一种轻量级，性能佳的Flutter DB管理框架；DB存储模型
Flutter IM架构的DB存储依赖数据库插件，目前主流插件是Sqflite，其存储模型如下：
依据上图Sqflite插件的DB存储模型会有2个等待队列，一个是Flutter层同步执行队列，一个是Native层的线程执行队列，其Android实现机制是HandlerThread，因此Query/Save读写在会同一线程队列中，导致响应速度慢，容易造成DB SQL堆积，此外缺失缓存模型，于是个人定制如下改进方案：
Flutter侧通过表的主键设计查询时候会优先从Entity Cache层去获取，若缓存不存在，则通过Sqflite插件查询，同时改造Sqflite插件成支持sync/Async同步异步两种方式操作，对应到Native侧也会有同步线程队列和异步线程队列，保证数据吞吐率；但是这里建议查询使用异步，存储使用同步更稳妥，主要怕出现多个相同的数据元model同一时间进入异步线程池中，存储先后顺序无法有效的保证；ORM数据库方案
IM架构重度依赖DB数据库，而当前业界还没有一个完备的数据库ORM管理方案，参考了Android的OrmLite/GreenDao，个人自行设计一套Flutter ORM数据库管理方案，其核心思想如下：
由于Flutter不支持反射，因此无法直接像Android的开源数据库方式操作，但可通过APT方式，将Entity和Orm Entity绑定于一身，操作OrmEntity即操作Entity，整个代码风格设计也和OrmLite极其相似，参考代码如下：
IM内存数据模型
FlutterIM架构在内存数据模型主要划分为会话和消息两个颗粒度，会话内存数据模型交托于SessionModuleData，消息内存数据模型交托于MessageModuleData；会话内存数据有一个根节点RootNotice，然后其挂载PSessionMessageNotice（这里PSessionMessageNotice是ORM映射的会话DB表模型）子节点集合；消息内存数据会有一个MessageConatiner容器管理，其内部挂载此会话中的PMessage(PMessage是ORM映射的消息DB表模型)消息集合。依据上一章节，PSessionMessageNotice设计了一个OrmEnitity Cache，考虑到IM中会话数是有限的，因此PSessionMessageNotice都是直接缓存到Cache中，这种做法的好处是各地去拿会话数据元时候都是缓存中同一个对象，容易保证多次重复读写的数据一致性；而PSessionMessageNotice考虑到其数量可以无限多的特殊性，因此这里将其挂载到MessageContainer的内存管理中，在退出会话的时机会校验容器中PMessage集合的数量，适当缩容可以减少内存开销，模型如下图所示：
状态管理方案
Flutter IM状态管理方案比较简单，对数据源Session/Message维度使用观察者模式的订阅分发方式实现，架构类似于EventBus模式，页面级的状态管理无论使用fish-redux，scopeModel或者provider几乎影响面不大，核心还是需保留一种插拔式抽象更重要；架构如下图：
IM同步模型方案
如下是当前现状的消息同步模型，模型中存在ACCS Thread/Main Thread/Region Thread等多线程并发场景，导致易出现多线程高并发的问题；native的推送和网络请求同步的隔离方案通过Lock的锁机制，并且通过队列降频等方式处理，流程繁琐且易出错。整体通过Region Version Gap去判断是否有域空洞，进而执行域同步补充数据。
改进的同步模型如下，在Flutter侧天然没多线程场景，通过一种标记位的转化同步异步实现类似Handler消息队列，架构清晰简约了很多，避免锁带来的开销以及同步问题。
进展以及性能对比
•针对架构层面：在FlutterIM架构中，重点将双端逻辑差异性统一成同一份Dart代码，完全磨平Android/iOS的代码差异性带来的问题，降低开发维护，测试回归，视觉验收的一半成本，极大提高研发效率；架构上进行重构分层，实现一种解耦合，插拔式的IM架构；同时Native到Flutter侧的大量数据上抛序列化过程改造成Flutter引用传递，解决极限测试场景下的私聊卡顿问题；
•针对线上舆情：补齐UT和TLog的集团日志方式做到可追踪，可排查；另外针对于很多现存的疑难杂症重点集中专项解决，比如iphone5C的架构在Flutter侧统一规划，未读红点计数等问题也在架构模型升级中修复，此外多媒体音视频发送模块进行改造升级；
•性能数据对比：当IM架构的逻辑层和UI层都切换成Flutter后，和原先架构模式初步对比，整体内存水位持平，其中私聊场景下小米9测试结果内存下降40M，功耗降低4mah，CPU降低1%；极限测试场景下新架构内存数据相比于旧架构有一个较为明显的改观，主要由于两个界面都使用Flutter场景下，页面切换的开销降低很多；
展望
JS跨端不安全，C++跨端成本有点高，Flutter会是一个较好选择；彼时闲鱼FlutterIM架构升级根本目的从来不是因Flutter而Flutter，是由于历史包袱的繁重，代码层面的维护成本高，新业务的扩展性差，人力配比不协调以及疑难杂症的舆情持续反馈等等因素造成我们不得不去探索新方案。经过闲鱼IM超复杂业务场景验证Flutter模式的逻辑跨端可行性，闲鱼在Flutter路上会一直保持前沿探索，最后能反馈到生态圈；总结一句话，探索过程在于你勇于迈出第一步，后面才会不断惊喜发现。